July Challenge

What characterizes a well-written computer program? To start off, here are four characteristics:

1. it works
2. it is readable
3. it uses consistent indentation and spacing
4. it is efficient

Who wants to add to this list?

Lee Bradley
May 26, 2023

Aaron West

5) Has a spec/documentation
6) Meets the spec/requirement(s).
7) Meets a need of at least one user
8) Is portable/deployable to the intended target platform(s)
9) (debatable) Does not duplicate functionality of an existing program,
   without adding performance or functionality

it is maintainable, but that might come from 2 and 3

10. well-chosen names for variables, functions
11. comments when they are useful
12. usage help if command tail involved
13. author, date in a comment
14. line count and variable count low
15. build script available
16. sample input and output available

Steve Marland

number 9 is a good one, i once had to maintain some code written in a
hurry by several people and there was quadruplication of many functions,
all just slightly different. Very difficult to maintain

Tom Gibson

I second the motion for all the above, 1 through 17, and maybe more not
submitted yet. But I urge #2 above as perhaps most important. I used to
say way-way-back when I worked (remember work?), "code should be
readable, and if it also worked that was a plus." I would say this
mainly to see the reaction of others. Most of my colleagues stressed
debugging. OK, we spent most of out time doing that. And that was in the
days of punched cards and hex dumps. Achieving #1 was our goal. But if
it wasn't readable it was not a contribution beyond the immediate work,
and in fact may well be a dis-contribution to that work, especially on
team jobs.

Lee Bradley

Thank you all for contributing to this thread.

Rob Leder

In general, I wouldn’t call anything well-written that isn’t reasonably
optimized (eg doesn’t perform some task as O(n) that with a little
thought could have easily been O(log n)). Most of what I work on employs
a microservice architecture, and in that world I’d say some good
development principles would be to avoid tight coupling and unintended
side effects, and strive for volatility-based decomposition - isolating
core functionality that should seldom if ever change from features that
are malleable or expandable.

Steve Marland

Ah yes, side-effects intended or no, can complicate things immensely.
Make a function do its job clearly and without fiddling with other
things - for those other things, make specific functions and call them
explicitly!